SOFAArk Committer 专访｜看它不爽，就直接动手改！

吕冰洁（花名：尚之）

蚂蚁集团技术专家

“

我们团队是在做蚂蚁集团内部 Serverless 项目，深度依赖 SOFAArk。SOFAArk 作为 Serverless 项目的核心热部署组件，在无感接入、快速启动方面有很大的诉求。

因此为 SOFAArk 2.0 提供了最核心的内嵌式运行模式，同时对 1.0 版本存在的一些问题做了较多的性能优化。

”

2022 年 03 月 07 日

吕冰洁@zjulbj 被投票选为

 SOFAArk Committer

Before

我主要是负责让传统的 SOFABoot 的应用平滑迁移到 SOFAArk 上。

开始走了很多弯路，接入成本上可能需要半个月到一个月。最初选择了新建应用切流这种比较间接的方案，基于这个方案做迁移过程中的平滑迁移、切流工具。

但是没解决根本问题，只是通过工具减少了部分工作量。

过程

我们就尝试通过修改架构把这些问题解掉，推动自己深入了解底层，思考它为什么是这么设计的，为什么导致现在的问题？

通过研究之后，发现最开始 SOFAArk 是面向终态去设计的，是比较理想化的容器。但实际落地过程中，业务是逐步演进而来的。刚接入就要感知特别大的变化，涉及部署脚本、镜像、测试脚本等一系列的改造，导致业务无法快速享受 SOFAArk 带来的红利。

我们就借鉴之前的经验，比如 Tomcat 最开始是一个容器，后面往内嵌化发展。我们内部的 CloudEngine 最开始也是一个容器，后面往 SOFABoot 演进也是一个往内嵌化的发展。

After

所以从我们整个迁移和落地的角度，设计了这套方案，修改其中的相关代码。

从原来需要 2~3 周到现在的一天，降低迁移的成本，省去了大量迁移工作。也为我们后面全站规模化、商业化的一键开启 ark 奠定了基础。

提问

Qustions

&

解答

Answers

1

作为业务研发深入中间件开发底层

如何看待自己作为业务研发的身份接触到开源？

作为业务研发，深入到开源组件的底层设计，不仅对我们自己使用组件有很大的帮助，也能让我们和开源社区的组件同步节奏，不至于脱节。

另外我们解决了实际问题，其他的使用方肯定也会遇到同样的问题。那我们是不是可以把已有的经验，回馈到开源社区帮助到更多的人。我觉得这是一个良性循环的开源环境，而不是向开发者提一些需求 pr 就结束了。

你觉得解决这个问题的难点在哪里？

主要的难点还是我以业务研发的身份，参与到整个 SOFAArk 中间件的开发中。

首先我需要对它的整个设计有清晰的把握，尽管之前有半年的使用经验，也依然花费了一周的时间才搞懂了核心架构。还好 ark 的文档写得很详细，大大降低了我的理解成本。

在沟通的过程中有没有什么困难的？

沟通没有困难，毕竟大家都是技术，其实都是相通的。只要把自己的使用场景说清楚，中间过程遇到的一些具体问题说清楚。然后结合整个社区的生态，思考一下自己的需求处于什么样的定位，毕竟大家都是基于问题出发。

也是通过这次深入开发底层，让我们更清晰的认识到大家都是绑在一条船上的，也更理解开发者，毕竟大家初心都是为了共同的目标去努力。

2

业务研发和开发者的双重身份

是否有可持续性？

这个状态还会一直持续下去吗？

目前我已经成为了 SOFAArk 2.0 的核心开发人员，还会推进 SOFAArk 在蚂蚁主站大规模落地，作为开发的角色维护下去的。本身我们的 Serverless 产品它下面依赖的部署组建就是 SOFAArk，我们要去大规模落地的过程中，涉及到对 ark 的一些支持问题，所以我们可能需要深入到底层去剖析，让组件真正的更易用。

业务研发深入到中间件底层设计，在开源社区是一个普遍的现象吗？

我理解应该是都有这样的现象，比如说我们用到动态热部署的能力，那我们对启动优化的东西，后面也会把它那个反馈到 SOFABoot、 Spring Boot 社区。

在我们自己落地过程中遇到的问题，想到的创新解决方案，如果是通用的话，会往各个社区去提 pr、做一些反馈的进行同步。

比如，我们在 SOFAArk 启动加速这一块，针对 Classloader 做了启动类加载的优化，启动速度平均提升了 50% 左右。

目前这个已经在 Spring Boot 提了 pr，他们那边正在跟进；

SOFABoot 这边也有相关的同学在保持跟进，之后我们会在我们主站率先去做一个 backport 的支持。

3

业务研发专属经验分享

SOFAArk 负责人说你是一个追求细节、追求极致的同学。

我们团队是做 Serverless 产品的，产品的要求是“更快、更高效、性能更好、体验更好”。

这就要求了我们在做代码优化的过程中去追求细节、追求极致，也是我们整个团队的风格。

有了这种特殊经历后，有哪些经验可以分享给其他业务研发的吗？

作为业务研发，最开始我对 ark 也不是很了解的，刚接手 ark 的迁移的东西，也没敢想说去对 ark 做这么大的改造。

一切基于我们团队的问题出发，一步步深入了解它的原理，去尝试实践自己想法，最终做出了开源的贡献，回过头来看才发现自己做了这么多。

大部分业务研发不太愿意去参与这种开源贡献，可能就是把它想得比较难了。

大家不用担心深入底层开发是很有门槛的事情，只要你带着问题出发，其他的都不是问题！

看他不爽，就直接动手改吧！

   本周推荐阅读